Automation control systems are well-known. Such systems include building automation systems for controlling environmental equipment, fire and safety equipment, security equipment, elevator banks, and the like. Other automation control systems include industrial control, food processing, and transportation systems. In general, these systems receive data from sensors that are evaluated to determine control actions to take in order to bring about some condition or perform some operation. For example, an environmental control system uses sensors to detect environmental conditions and system parameters throughout a building or other space to determine control actions that are necessary to bring the regulated space to some defined condition.
In modern systems, the advent of relatively inexpensive processors has allowed manufacturers to incorporate processors into many of the various components within such systems. Accordingly, each of the devices in the system may be a “smart” device. Such a device is capable of doing at least some level of data manipulation. Additionally, the devices may be equipped with a transmitter allowing the device to provide data to the network. The device may further include a receiver to receive data from the network. Accordingly, even sensors may be smart devices, transmitting data to the network.
There exist a wide variety of sensors for a wide variety of purposes. Sensors can include temperature sensors, infrared body detectors, position indicators, water flow meters, air flow meters, water pressure meters, air pressure meters, and the like. Position indicators, for example, are devices that generate a signal that corresponds to the position of a switch, valve, or vent opening so the system controller may determine whether particular lights, fans, vents, or blower motors are operating or open. The data that is generated by the sensors is provided to one or more controllers in the control system. The data may be provided directly to the controller, or by transmission through the network.
The controllers in many cases compare the data to desired values for the particular sensed condition. The desired values are called set points. The controllers perform control actions to bring the sensed parameters into compliance with the conditions corresponding to the set points. In some cases, sensors that sense one condition may be used to effect control of another condition. For example, a sensor data that indicates a person's entry into a room may be used to initiate control actions to achieve lighting, ventilation, and thermal comfort conditions specified for an occupied space. Such control actions may include the activation of blower motors to bring conditioned air into the room through vents that are also opened in response to control signals generated by the controller.
Additional control actions may involve obtaining temperature sensor data and controlling the various devices to maintain the desired temperature. In this manner, the controller may regulate the environmental conditions in a space.
The use of smart devices in a system allows for the control of the system to be de-centralized or distributed. Distributed processing may be used in an environmental control system to coordinate control of the system with the various heating, ventilation and air conditioning (HVAC) functions in the system. For example, an air-handling unit (AHU) in an HVAC system distributes conditioned air to several variable air volume (VAV) terminals in a building. Thus, VAV controllers exchange data with the AHU controller so the AHU appropriately provides conditioned air to the VAVs and the AHU controller may synchronize the operation of these local space controllers.
Different companies, however, frequently manufacture the various devices within a control system. Accordingly, it is possible that a device manufactured by a first company would have a communication protocol different from the protocol used by a device manufactured by a second company. When devices of a system employ different protocols, the consumer must absorb the expense of creating an interface system for the various devices. Alternatively, the consumer may limit the system to devices from a limited number of manufactures, all of whom employ the same protocol.
In response to this problem, various “standard” communications protocols have evolved which are used by a number of different manufacturers. A benefit of such protocols is to allow for interoperability between devices produced by the various manufactures. In an interoperable environment, by ensuring that a replacement device uses the same protocol as the rest of the network, a consumer can purchase a device with the assurance that the device will be able to communicate with the rest of the consumer's system once installed. One such protocol is the LONTALK protocol, also known as the ANSI/EIA 709-1 Control Networking Standard.
The LONTALK protocol is a layered, packet based, peer-to-peer communications protocol designed specifically for control systems. Typically, standardized deployment of the protocol is achieved by the use of a NEURON Chip, commercially available from Toshiba America Electronic Components, Inc., of Irvine Calif. and Cypress Semiconductor Corporation, of San Jose, Calif. The NEURON Chip is programmed with all levels of the communications protocol with the exception of the application level. Accordingly, to allow for interoperability, a manufacturer may incorporate a NEURON Chip in a device.
Of course, use of a NEURON Chip does not mean that a device is interoperable with other devices incorporating NEURON Chips. This is because the application level of the device is programmed by the individual manufacturer in accordance with the manufacturer specific design of the device. To ensure interoperability, the inputs and outputs of the device at the application level must also be standardized. This is accomplished in a LONTALK protocol device by the use of standardized functional profiles. Standardized functional profiles are discussed more fully below. In essence, however, the standardized functional profiles establish common data formats that are used for passing data at the application level.
Accordingly, by using devices with a shared protocol that fit standardized functional profiles, a consumer ensures that a new device, regardless of its manufacturer, will be capable of sending messages to and receiving messages from other devices already in the network. To this end, the protocol ideally enables communication without prior detailed knowledge of the topology of the network. In other words, a single device may be used within networks having diverse topologies. Obviously, the individual installing the device must be aware of the network topology so as to allow for necessary bandwidth and interconnections. However, assuming that the installer has properly accounted for the topology prior to installing a device, the device will be able to communicate with other devices in the network. This capability is enabled by maintaining control functions within the various devices while passing data between the devices in the system using the protocol. Such a system may be referred to as an information-based control system.
A network based upon the LONTALK protocol allows remote network management tools to interact with components over the network, including reconfiguration of network addresses and parameters, downloading of application programs, reporting of network problems, and start/stop/reset of component application programs. Beneficially, the network may be implemented over basically any medium, including power lines, twisted pair, radio frequency (RF), infrared (IR), coaxial cable and fiber optic or combinations thereof.
Communications protocols such as LONTALK provide significant advantages in implementation of a distributed processing system. However, there are some difficulties associated with such protocols. One such problem arises when devices are replaced with either devices from a different manufacturer or even updated devices from the same manufacturer. Devices that are configured in accordance with the LONTALK protocol are referred to as LONWORKS devices. However, a replacement LONWORKS device is typically not configured to interface with a system in the same manner as the LONWORKS device being replaced. For example, a single device may be useful in a number of configurations, each configuration using and creating a different set of input and output data.
The primary means of accessing data within a LONWORKS device is via Network Variables (NVs) and Configuration Properties (CPs). The NVs are utilized for “dynamic” data within the control application. An example of dynamic data is current zone temperature. The NVs are the primary mechanism by which data is exchanged between control and monitoring nodes on the network. The CPs are utilized for “static” data. A CP can be configured as one of two entities, a configuration property type (CPT) or a configuration network variable (CNV). A CNV follows rules established for NVs and count against the limit of NVs that can be used with a particular node. However, a CPT is not so limited, since the CPT ultimately resides within the device. Thus, limitations as to number and size for CPs associated with a node is a function of the memory capacity of the node and the processor associated with the node.
The static data of CPs are typically stored in a controller's non-volatile memory and can be used to configure the application and/or control parameters within the controller. Static data can be used to configure, for example, input and output configuration and set points. NVs and CPs are identified, among other things, by a name and a type. The “name” identifies the class of sensor, such as a temperature sensor. A data “type” defines the units, scaling and structure of the data being passed. A number of standard NV types (SNVTs) and CP types (SCPTs) have been created for commonly used types. Additionally, the LONTALK protocol allows for user defined NVs and CPs, referred to as UNVTs and UCPTs. Collectively, the NVs and CPs within a LONWORKS Controller are referred to as the Node Interface. In addition, NVs and CPs within a controller may be organized and/or associated with Objects.
The application layer programming for LONMARK devices is object-oriented, hence the grouping of NVs and CPs into Objects. An Object is a modular segment of code that performs a documented function using defined inputs and producing defined outputs. In a given device, one or more Objects may be grouped together to perform the function(s) of the device. The Node Interface for a device is thus the amalgamation of the NVs and CPs of all of the objects programmed into the device, along with defaults and power-up behaviors
In the LONTALK protocol there are two types of defined Objects, generic LONMARK Objects and LONMARK functional profiles. A generic LONMARK Object may be a sensor that can be used in a number of different applications such as lighting, security, or a manufacturing system. A LONMARK functional profile is an Object that is defined within a specific application. For example, in the HVAC area, a controller used to control a damper actuator based upon a control algorithm using a sensed temperature will require a temperature input and will generate a control output. Accordingly the functional profile for the controller will define the format of a temperature input and the format of the control output. The functional profile will further define optional NVTs and CPTs. Manufacturers may choose to include any number of the optional NVTs and/or CPTs in a particular device. Therefore, devices from different manufacturers may be based upon the same functional profile, while having different Node Interfaces because of the selection of different optional NVTs and CPTs.
LONWORKS devices include “self-documentation” of the Node Interface requirements of the device that can be read and interpreted by a LONWORKS tool. Recovery and interpretation of the self-documentation from a LONWORKS node is the primary and most rudimentary mechanism by which a LONWORKS tool obtains information on a node's Node Interface. Self-documentation includes a Program Identification (Program ID).
Each Node Interface must be assigned a Program ID. Rules for assigning Program IDs and guidelines for self-documentation are administered by the LONMARK Interoperability Association and may be found in LONMARK Application Layer Interoperability Guidelines. In accordance with those guidelines, nodes containing the same Program ID must contain the same Node Interface. Thus, it is assumed that LONWORKS devices with identical Program IDs have identical NV and CP names, the same number of NVs and CPs, identical organization into Objects, etc. Accordingly, when the self-documentation of a node changes, the Program ID of any device at the node must also be changed.
Typically, but not always, descriptive NV names are included in the self-documentation stored within the LONWORKS node as provided by the manufacturer. However, such storage obviously requires memory space. Thus, due to memory constraints, some nodes do not include NV names in the self-documentation stored within the nodes. In such cases, LONWORKS tools must rely on other means for associating an NV with a descriptive name. The most common, and indeed de facto standard for doing so, is to utilize what is known as an External Interface File (XIF file).
The XIF format is determined and maintained by the LONMARK Interoperability Association in the LONMARK Device Interface File Reference Guide. The data in the XIF file includes a Program ID. A Program ID is an identifier for a device that includes a manufacturer identification, a device class, a device subclass and a model number. The device subclass identifies the device as having a specific functional profile. Thus, all devices within the same device subclass must have the same functional profiles. However, by identifying a specific model number, the Program ID further identifies the specific Node Interface for the device. The XIF file is thus a text file description of the Node Interface that can be used by tools to provide access to an application's Node Interface without the need to retrieve the data from the actual node.
A network management tool may be used to obtain the Node Interfaces of the various devices when initially installing a system. The network management tool is a program loaded into a computer, which may be, for example, a portable computer, a handheld device, or an administrative computer connected to the system. The network management tool may be identified as a special node on the system.
After the Node Interfaces are determined for the devices in the network, a process referred to as “binding” is performed. The binding process establishes the logical connection between the devices by connecting the NV Outputs (NVOs) from one node or nodes to the NV Inputs (NVIs) of the same type on another node or nodes. From a network perspective, the devices can thus be thought of as nodes having specific configurations. The logical connections are then stored within the network management database used by the system. Typically, this file is called a Network Management Database or a Network Configuration Database. The logical connections are further stored in the network image of the node. The network image of the node is the configuration table maintained by the node to identify messages on the network that are to be received by the node and to identify outputs that the node is to transmit.
When a replacement device is connected to the system, the network image of the replacement device must be established and stored both in the replacement device and in the network management database. If the replacement device is identical to the previous component, i.e. the same Program ID, establishing the network image may be fairly simple. Some network management tools have the capability of verifying the Program ID, and merely configuring the replacement device using previously defined data by copying the former network image into the new device.
However, in the event the replacement component has a different Program ID, prior art network management tools assume the node to be completely different, and do not automatically attempt to establish the logical connections to the device or provide CPs to the replacement device. Thus, even if the replacement device uses an identical functional profile but is provided by a different manufacturer or even if the device is from the same manufacturer but has a new model number, there is no automatic attempt to configure the node using previously defined data.
Moreover, if the original network management database is not available and a network image cannot be recovered by the network management tool following some damage to the node, then the new node must be manually configured. The design limit for host-based nodes is 4096 NVs, and an unlimited number of CPs. Obviously, manually configuring such a node is labor intensive in engineering and testing.
What is needed is a network management tool capable of automatically re-establishing NV connections and setting the values of CPs even when a node is replaced with a device having a different Program ID. It would be beneficial if the network management tool were capable of identifying conflicts or changes in node configuration, allowing a user to quickly assess the conflicts or changes. It would be further beneficial if the network management tool provided potential conflict resolution options.